Leveraging model-based product lines for systems engineering. (Exploitation des lignes de produits fondées sur les modèles pour l'ingénierie système)

Semantic 1 Semantic 2 Derivation Semantics Base Models yes! yes! no! Resolutions Features Derivation Operators MSPL DSL1 DSLn Semantic 3 ! Semantic 4 D1! D2! D3! F i g u r e 1 . 3 : S e m a n t i c s v a r i a t i o n o f d e r i v a t i o n o p e r a t o r s . 1.3.2 Semantics specialization mechanisms C V L p r o v i d e s m e a n s t o b e s p e c i a l i z e d : i t h a s a s e m a n t i c a l l y c u s t o m i z a b l e d e r i v a t i o n o p e r a t o r c a l l e d O p a q u e V a r i a t i o n P o i n t ( O V P ) . A n O V P w o r k s l i k e a n e x t e n s i o n p o i n t , a l l o w i n g t h e i m p l e m e n t a t i o n o f “ h o m e m a d e ” s e m a n t i c s a s a b l a c k b o x t h a t c a n d e fi n e And after all, is it safe? 17 an arbitrary behaviour to be executed during derivation. Besides the OVP, practitioners can also introduce new derivation semantics statically inside the code of the CVL derivation engine and the second one is using the strategy pattern, but also inside the derivation semantics. We have analysed the different mechanisms used to customize the CVL semantics in 4, as well as their advantages and disadvantages. 1.4 And after all, is it safe? The design space (also called domain engineering) of an MSPL defined with CVL is extremely complex to manage for a developer. First, the number of possible products of an MSPL is exponential to the number of features or decisions expressed in the variability model. Second, the derived product models6 have to conform to numerous well-formedness and business rules expressed in the modeling language (e.g., UML exhibits 684 validation rules in its EMF implementation). The number of derived models can be infinite while only part of the models are safe and conforming to numerous well-formedness and business rules. Consequently, the engineer has to understand the intrinsic properties of the modeling language when designing an MSPL. The two modeling spaces (variability and working domain) should be properly connected so that all valid combinations of features (configurations) lead to the derivation of a safe model. In CVL, as in many MSPL approaches, the realization layer is crucial and should be properly managed. Specifically, managing the design space of an MSPL raises two key issues. First, the realization model specifies how to remove, add, substitute, modify (or a combination of these operations) model elements. Elaborating such a model is errorprone because, for example, it is easy for an SPL designer to specify instructions that delete model elements that are dependent on others (e.g., deleting a super class of a class without deleting also the class) for a given combination of features [CP06], or perhaps to forget a constraint between features in a variability model and allow a “valid” configuration despite the derivation of an unsafe product (this is illustrated in detail in Section 2.6 of Chapter 2). Second, the derivation engine executes the realization model and produces a product model that has to conform to the syntax and the semantics of the modeling language. Assuring the correctness of the derivation engine for a given modeling language is still a theoretical and practical problem. 1.5 Engineering MSPL in industry needs special assistance Because of the combinatorial explosion of possible derived variants, the great variety and complexity of its models, correctly designing a Model-based Software Product Line 6CVL uses the term materialization to refer to the derivation of a model. Also, a selected/unselected feature corresponds to a positively/negatively decided VSpec. We adopt the well-known vocabulary of SPLE for the sake of understandability.